Web API Verification: Results and Challenges

Modern Web applications use several APIs to build rich features. For example, the W3C Geolocation API provides access to a user’s physical location for location-based personalization, Facebook Connect provides a single sign-on service and access to a user’s social graph, Local Storage is a per-domain cache that enables offline access, and the Google Maps API allows applications to embed customized maps. Some of these APIs, such as Geolocation and Local Storage, are built into Web browsers, whereas others, such as Facebook Connect and Google Maps, are provided by Web services. These APIs are carefully crafted, since they give applications access to sensitive information. However, security bugs are constantly found that affect API providers, Web applications, and end users. Some APIs are security-specific. For instance, ADsafe [2] and Caja [6] are systems designed to securely sandbox content combined from non-mutually-trusting authors on a single Web page. Through a combination of static and runtime checks, these systems aim to provide certain security guarantees to the content and/or the hosting page. In such cases, where the authors may be actively malicious, verifying the APIs is critical. Other APIs were not designed with security in mind, but security concerns arose as they became widely implemented and programmers understood their full potential. Consider the XMLHttpRequest API, which allows JavaScript programs to send HTTP requests to Web servers. When first released, a malicious JavaScript program using XMLHttpRequest could trivially set special HTTP headers that caused Web servers to misinterpret requests. Web browsers now blacklist several headers. Mozilla Firefox has an Extension API, which thirdparty extensions use with great effect. However, third-party extensions run with the same privileges as Firefox’s code. Mozilla thus has an arduous, error-prone review process to vet extensions. In principle, these APIs are reference monitors, which should be small and verifiable. In practice, these APIs have several entry points with complex static and runtime checks, resulting in a large attack surface that a large attack surface, complex runtime checks, and several entry points that could be compromised. For example, the Firefox extension API has over 1, 000 types, some of which allow access to sensitive resources such as local files. ADsafe has only 1, 800 lines of code, but 95 runtime security checks. A missing or misused security check could compromise the safety of the entire system. Moreover, these APIs do not crisply state their security goals, which makes verification difficult. Designing and implementing these APIs securely, and verifying that this has been done, is hence an important challenge.